Per tax advisor consultation with Naczelna Izba Skarbowa and Art. 63
Ordynacja Podatkowa, rounding should only be applied to final tax base
and tax amount sums, not to individual transactions.

Change default behavior to carry full f32 precision through per-transaction
FX conversions. The previous per-transaction rounding to grosz is preserved
as an opt-in flag:
  - CLI: --round-per-transaction
  - GUI: Options menu toggle (MenuBar)

Also add default-run to Cargo.toml to resolve binary ambiguity.

Signed-off-by: Mateusz Bronk <mbronk@users.noreply.github.com>

Signed-off-by: Mateusz Bronk <mbronk@users.noreply.github.com>

Replace all f32/f64 money types with rust_decimal::Decimal for precise
financial arithmetic. This eliminates floating-point representation
errors in tax computations.

Motivation: starting at 131,072 PLN (2^17), f32's ULP reaches 0.015625,
exceeding 0.01 PLN and making it impossible to represent individual grosz
values correctly. Any realistic portfolio of ~$30k+ in US stock sales
converted at ~4 PLN/USD crosses this threshold.
A new test (test_decimal_precision_vs_f32_sold_taxation) demonstrates a
concrete 1-grosz error on a PIT-38-realistic scenario with just 3 trades.

Key changes:
- Add rust_decimal 1.36.0 (macros, serde-with-float features)
- Convert all money types (Currency, Transaction, SoldTransaction,
  TaxCalculationResult) and rounding functions to Decimal
- Update parsers: PDF uses DecimalEntry; CSV parses &str→Decimal
  directly; XLSX converts calamine f64→Decimal (IEEE 754 unavoidable)
- NBP rates: serde-with-float deserialization, cached rates as dec!()
- ECB rates: Decimal division for inverse exchange rates
- Round gross_sold/cost_sold to grosz in run_taxation output
- Add rust_decimal.natvis for VS debugger visualization
- Add proof test for f32 grosz error; update all existing tests

Signed-off-by: Mateusz Bronk <mbronk@users.noreply.github.com>

What:
Use Trade Confirmation commission/fee data to increase tax cost basis while
keeping sale proceeds reported as gross proceeds (separate fields).

Why:
- Polish PIT-38 capital-gains reporting requires separate values for proceeds
  (przychod) and deductible costs (koszty uzyskania przychodu).
- Booking brokerage fees into costs (instead of blending into proceeds)
  keeps reconstructed SELL data aligned with tax-form semantics.

How:
- Parse Trade Confirmation PDFs and extract trade_date, settlement_date,
  quantity, price, principal, commission, fee, and net amount.
- Match confirmations to sold rows using normalized
  (trade_date, settlement_date, quantity, price, symbol).
- Allocate same-day, same-symbol G&L lots to sold rows via
  quantity-constrained DFS/knapsack matching.
- Reconstruct sold transactions by proportional fee allocation per matched row.
- Store fees separately and add them into cost basis; keep proceeds and costs
  as distinct output values.
- If confirmation matching remains ambiguous even after price matching,
  continue with deterministic selection and emit explicit warnings
  (including principal/net candidate diagnostics) surfaced in CLI and GUI notes.
- Strengthen validation and diagnostics to distinguish missing statement entries
  from quantity/symbol inconsistencies.
- Keep integer-only quantity handling from G&L.

Signed-off-by: Mateusz Bronk <mbronk@users.noreply.github.com>